While computers are still used for their traditional processing purposes, advances in communication infrastructures and protocols have turned standard computing devices into valuable communication tools. Computers communicate with each other, and with other electronic devices, over networks ranging from local area networks (LANs) to wide reaching global area networks (GANs) such as the Internet. Other electronic devices have experienced similar transformations, such as mobile phones, personal digital assistants (PDAs), and the like. Today, these wireless devices are being used for a variety of different types of communication. For example, while the analog mobile phone was traditionally used for analog voice communications, the mobile phone of the present and future is a powerful communication tool capable of communicating voice, data, images, video, and other multimedia content. PDAs, once the portable calendaring and organizational tool, now often include network communication capabilities such as e-mail, Internet access, etc. With the integration of wireless and landline network infrastructures, information of all sorts can be conveniently communicated between wireless and landline terminals.
In carrying out such communications between devices, the programs, applications, application instances, and the like (hereinafter “applications”) operable on such devices often need to communicate with applications on other devices. For example, an application at the application layer may generate messages that are communicated to lower levels of the software architecture including, e.g., the transport layer, network layer, data link layer, and physical layer, where the encapsulated messages are transmitted over the network to other devices. Messages received at the receiving device move up the software architecture to ultimately provide the original message to an application on the receiving device.
Modern packet data networks, such as Internet Protocol (IP) networks, are in wide use today and they employ such a hierarchical architecture. IP networks are arranged to operate end-to-end between network hosts and corresponding network terminals, where IP routers supply, for example, data packet forwarding functionality. Exemplary transport protocols implemented within the transport layer include: User Datagram Protocol (UDP), which allows a connectionless datagram service where connection setup is not needed or when overhead should be reduced; and Transmission Control Protocol (TCP) that allows connection-oriented reliable delivery with congestion control and retransmission for data recovery.
Congestion in a network is loosely defined as a condition where demand for resources, e.g., bandwidth, Central Processing Unit (CPU) time, or memory, exceeds capacity. Congestion control aims to alleviate the problems caused by congestion, where congestion control may be divided to two parts: congestion avoidance; and congestion recovery. Congestion avoidance tries to prevent demand from exceeding capacity, while congestion recovery tries to restore an operative state. It is possible for network entities, such as IP routers, network hosts and network terminals, to contribute to both of these mechanisms. When a network entity, such as an IP router, receives a packet beyond its storage capacity, it must implement a data reduction algorithm in order to prevent data overflow, while maintaining adherence to the applicable Quality of Service (QoS) policy that may be in force. In order to achieve the varying QoS levels enforced by the IP network, the IP router may utilize data packet queues to facilitate, for example: packet drop; packet transfer delay; prioritized packet transmission; or data packet modification and data packet repack.
One example of a QoS network is based upon the Differentiated Services (DiffServ) framework that has been standardized by the Internet Engineering Task Force (IETF). The basic idea of DiffServ networks is that ingress data packets receive stamps called DiffServ codepoints at the point of ingress, or at the edge of the DiffServ network. IP routers that subsequently come into contact with the data packet then base their handling of the data packet upon the value of the DiffServ codepoint. For example, if there is a high enough level of congestion in the IP router, then the IP router can start to drop packets with low enough priority classes in accordance with the associated DiffServ codepoint. This QoS handling of the data packet, however, is performed locally by each individual IP router, based upon the initial DiffServ codepoint, without consideration for QoS actions taken by neighboring IP routers.
Voice over IP (VoIP) calls, or video streaming, is one example of an application that may be adversely affected by such localized handling of data packets. Normally, this kind of application can handle data interruptions, such as packet loss or delayed packets, if they are separated in time. Upon such a data interruption, the applications, e.g., audio codecs, may employ data replay, for example, of the last successfully received data packet. In many cases, the data replay results in little, if any, data interruption detection by the user. If, however, the QoS related actions to the same connection occur consecutively, or too frequently, then the application will likely fail due to an intolerable decrease in QoS caused by the consecutive data loss.
Additionally, if other IP routers in the forwarding path select the same data connection for QoS actions, then a possibility exists that the cumulative QoS actions of the daisy chained IP routers will adversely affect the final QoS of the affected connection path. Thus, from an end-to-end (e2e) point of view, the receiving application is still the recipient of excessively delayed, or even dropped, data packets. QoS methods employing the end-to-end (e2e) methodology, e.g., Integrated Services, have been implemented to alleviate problems associated with the local QoS operations. The e2e QoS methods developed by the IETF, however, require heavy control, signalling, and management functions to be implemented within the IP routers and thus have not enjoyed widespread use due to their excessive processing requirements.
It would, therefore, be desirable to implement a QoS solution that provides an expanded view of the cumulative QoS operations being performed on a particular data connection, while decreasing the amount of processing required of the e2e QoS methods. The present invention provides a solution to these and other problems of the prior art, and provides many advantages over prior art QoS methodologies.